Subject: Number of TCP/IP Connections

From: Robin Layland <[email-masked]>
Date: Fri, 1 Oct 93 19:39 GMT

Disclaimer: I know this is not the right group to bring it up and that the issue
got move to the COS 
group but I am bring the issues up here for two reasons: (1) I feel moving it to
the COS group was 
a way of trying to kill the issue and it is to important to do that to and (2) I
am not a member of the 
COS group and I have yet to figure out how I send something from MCI Mail to an
Internet 
address.
 
Issues: Number of sessions;
 
Base: Base should specify two sessions. One session is for data traffic. This is
a duplex session. 
The second session is for control. Control include the first session started for
capabilities 
exchange. IPM also flow on this session. I would like it to say that Pacing
responses should be 
carried on data messages when possible. If all pacing is IPMs then this will
generated to much 
traffic.
 
Option: A field in the capabilities exchange that specifies the number of data
sessions. If 
number=1 then its is the base. If number > 1 then it is an option. The
additional session would 
carry traffic. The sender would determine which session the circuit goes on. The
secondary DLSw 
would follow the lead of the sender. If the number=3 there would be four
session, three data and 
one control. If a circuit is started on data session number 2, the secondary (or
receiving) DLSw 
should put the return traffic also on data session number 2.
 
Reason: This will allow session to set put on data session by priority. If I
want three priorities, then 
number =3, and the DLSw enforces priority number 1 one session number 1,
priority 2 on session 
2 and so one. If I want only one session per TCP/IP connection then I have to
ask for the 
maximum number of circuits that will be needed. If the DLSw switch supports 20
circuit at a time 
then number =20. 
 
Problem: This works find if one DLSw starts all the sessions. The question is
how do I tell the 
second DLSw that the three sessions are for priority one, two and three traffic?
The second DLSw 
could use any session for any traffic. Maybe COS group could add to the option
to make it work 
when the number>1 and the extra sessions are for priority.  Also, how do I tell
the secondary 
DLSw that there should be only one circuit per connections. 
 
Problem: What if more connections are needed after capabilities are exchanged.
 
Good part: Having number>1 as a option addresses the problem of needing more
sessions for 
performance reason. It also allows a base (or option base) that will allow COS
and one circuit per 
connection to be built.
 
I am not say this solve all the problems but it is more flexibility than the
current set up. It also 
allows the base to kept two session and use the well know port numbers. This
will require few 
changes to existing implementations. It is easy to argue against the present set
up. Two session 
used as half-duplex is not very logical, doesn't have good performance and the
rest. Lets clean 
this up now while we have a chance and it would require few changes.
 
Comments? 

Robin Layland

---

From: "Jim (J.) Cobban" <[email-masked]>
Date: Mon, 4 Oct 1993 14:08:00 +0000

In message "Number of TCP/IP Connections", 
[email-masked]' writes:

> (1) I feel moving it to the COS group was 
>a way of trying to kill the issue and it is to important to do that to ...

I presume that you meant that it is important to NOT kill the issue.

I am certain that there was never any intention to kill the issue of 
handling different numbers of TCP connections.  The conflict that arises is
that we wanted to reduce the number of competing topics to a handfull.  In
doing so we had to arbitrarily assign various issues to one or other of the 7
remaining SIGlets.  In particular there are at least four  major aspects to the
issue of how TCP connections are used:

  1) avoiding deadlock which can occur if the TCP congestion mechanism
     prevents aacknowledgements from being delivered.  This falls in the
     domain of the flow-control SIGlet.
  2) handling different priorities and classes of service by mapping them to
     specific TCP connections which have appropriate characteristics.  This
     falls in the domain of the COS/Priority SIGlet
  3) deciding how many connections to establish.  This falls in the domain
     of the Capabilities SIGlet
  4) deciding when to set up and take down individual TCP connections.
     There is some disagreement on whose responsibility this is.  The
     superficially obvious location is the Connect SIGlet.

The result, of course, is that nobody is in charge of the total area.  This
may be entirely appropriate at this level of discussion.  There are clearly
competing demands which should all be voiced, and then brought together once
they are all analyzed and understood.

>carried on data messages when possible. If all pacing is IPMs then this will

While we are agreed that the base is for two TCP connections, I do not
believe that there is consensus on exactly how those connections are used.
The model you describe is designed to deal with the deadlock concerns, but
does not, necessarily, deal with other concerns.  I also do not believe that
it is the model of usage which is present in the current 6611 implementation.
My understanding is that the 6611 (which does not have capabilities exchange,
or IPMs) uses the two TCP connections as simplex pipes, much in the same way
that two APPN CPs use a pair of LU 6.2 pipes.  I would suggest that the BASE
capability should be as close as possible an emulation of the 6611 usage.  

The issue of whether pacing is piggybacked on data messages, or carried in
IPMs, is largely independent of the question of how many TCP connections to
use.  I say largely independent because pacing responses which are
piggybacked on data can be delayed by congestion management, while IPMs may
flow freely because their separate priority pipe bypasses the problem.  To my
mind it probably will cause incredible headaches if piggybacked pacing
responses and IPMs are transported by independent mechanisms so that the IPMs
can overtake the piggybacked responses.  I certainly would not want to have
to design a reliable flow control mechanism with those assumptions.

>should put the return traffic also on data session number 2.

I have a gut feeling that we will need to define several different flavors of
the multi-transport SSP.

 - There may be value in supporting a model in which there is a single pipe 
   which is used for all traffic in both directions.  This is in line with 
   recent moves to support Two-way simultaneous traffic on LU 6.2 for those
   applications which do not require the checkpointing capabilities.
 - The 6611 model of two simplex pipes, with the addition of piggybacked
   flow control and possibly in-line IPMs (with the theoretical possibility
   of deadlock).
 - The model of a separate control pipe which permits congestion management
   to operate at a higher priority, or at least a separate priority, from
   normal data traffic, and thereby avoiding the theoretical possibility of
   deadlock.  I repeat "theoretical possibility" because there are many
   successful protocols, including APPN ISR, which perform in a satisfactory
   manner while carrying flow control signals within the normal data path.
   The counter-examples are SNA subarea in which VR pacing is carried at
   network priority, and HPR.  Before we add this complexity, which includes
   the unavoidability of the additional IPM traffic which you object to, we
   must be absolutely convinced that we cannot achieve reasonable performance
   without it.  I will also point out that the 6611 has no existing flow
   control mechanism and it has many satisfied customers.
 - The addition of other data pipes, probably simplex as in the 6611,
   possibly duplex, as negotiated by capabilities exchange.

Support of each of these flavors would require a different option indicator
in the capabilities exchange.

>maximum number of circuits that will be needed. If the DLSw switch supports 20

You started out by complaining that this topic had been shoved into the
COS/priority SIGlet in order to kill it, but these arguments in favor
of it are COS/priority arguments.

It seems logical to me that there will need to be a functionality equivalent
to CNOS which permits dynamically changing the number of underlying transport
connections.  It also seems reasonable that there will need to be a transport
connection level capabilities exchange as well as a switch level exchange in
order to negotiate the use of a particular pipe.

This leaves the one clearly ambiguous aspect of this, which SIGlet is
responsible for determining the mechanism for activating and deactivating
individual transport pipes under the SSP.  As I said at the top the obvious
candidate would be the Connect SIGlet.  The Connect SIGlet is currently
responsible for resolving concerns related to data link control dependencies.
Since the high-level capabilities of the switch-to-switch connection are the
same as the high-level capabilities of the "external" connections (see my
other document on the Connect mailing list) this might seem logical.  However
I believe that to treat the activation and deactivation of transport pipes
under the SSP as part of the Connect process strikes me as sloppy layering.

The Connect SIGlet is concerned primarily with mapping the topology discovery
and logical link connection establishment portions of the SSP protocol to
logical equivalents in various other media transports for SNA and NetBIOS.
As such it largely ignores issues such as how to select between multiple
bridge paths across an 802.5 TRN.  To the SSP itself the particular set of
bridges chosen to deliver frames belonging to a particular connection is
irrelevant.  The Connect SIGlet also does not care how many routes are used for
different connections going to the same destination LAN segment.  

I think what we need to examine in the Connect Siglet is how a desired class
of service or priority is signalled to the SSP.  Given that information I
believe that it is the responsibility of other groups to decide on how this
one particular implementation of a data link protocol delivers data to the
far end.  I do not think that the Connect Siglet, which is concerned with
establishing individual logical link connections across the available
data link subnetwork implementations, should be involved in how a pair of SSP
implementations select their underlying transports.